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Beschreibung 

Betriebsverf ahren fur einen Server und hiermit korrespondie- 
rende Gegenstande 

5 

Die vorliegende Erf indung betrif ft ein Betriebsverf ahren fiir 
einen Server, der mit einem Client kommuniziert, wobei der 
Server, wenn ihm vom Client eine Anforderung fiir eine Seite 
tibermittelt wird, die angeforderte Seite an den Client iiber- 
10 mittelt. 

Die vorliegende Erfindung betrif ft ferner einen Datentrager 
mit einem auf dem Datentrager gespeicherten Computerprogramm 
zur Durchfiihrung eines derartigen Betriebsverf ahrens . 

Die vorliegende Erfindung betrif ft weiterhin einen Server mit 
einem Massenspeicher, in dem ein Computerprogramm hinterlegt 
ist, so dass bei Aufruf des Computerprogramms von dem Server 
Rechner ein derartiges Betriebsverf ahren ausfuhrbar ist. 

Derartige Verfahren, Computerprogramme und Server sind allge- 
mein bekannt. Sie werden insbesondere bei Web-Anwendungen, z. 
B. bei Internet- und Intranet-Anwendungen, eingesetzt. 

Web-Anwendungen sind relativ anonym. Der Server und der 
Client wissen in aller Kegel sehr wenig voneinander. Insbe- 
sondere ist es dem Server in aller Regel nicht moglich, an- 
hand einer Anforderung fiir eine Seite ohne Weiteres zu ermit- 
teln, von welchem Client ihm diese Anforderung iibermittelt 
30 wurde und aus welchem Zustand des Clients heraus die Anforde- 
rung erfolgte. Jede an der Server gerichtete Anforderung muss 
daher in der Regel eine vollstandige Information iiber den an- 
fordemden Client und iiber die angef orderte Seite enthalten. 



20 




35 



Um innerhalb einer Sitzung zwischen Server und Client (= Ses- 
sion) serverseitig dennoch gewisse Voreinstellungen (z. B. 
eine Auswahl einer Sprache, die im Folgenden stets benutzt 
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werden soil) -treffen zu konnen, ist es insbesondere bekannt, 
dass der Client sich zu Beginn der Sitzung beim Server anmel- 
det und dieser zusatzlich zur angef orderten Seite eine An- 
hangseldatei (ein sogenanntes Cookie) an den Client ubermit- 
5 telt. Die Anhangseldatei wird vom Client jeder an diesen Ser- 
ver gerichteten Anforderung beigefugt. Sie wird also vom 
Client an den Server zuruck ubermittelt. Die Anhangseldatei 
ist dabei spezifisch fiir den Server. Sie wird vom Client also 
bei jeder an diesen Server gerichteten Anforderung mit an den 
10 Server ubermittelt . Die Ubermittlung der Anhangseldatei er- 
folgt so lange, bis entweder die Anhangseldatei auf Seiten 

•des Clients geloscht wird Oder vom Server eine neue Anhang- 
seldatei an den Client ubermittelt wird, so dass die bisheri- 
ge Anhangseldatei uberschrieben wird* 

15 

Die Voreinstellungen, die getroffen werden sollen, konnen in 
der Anhangseldatei selbst enthalten sein. Alternativ kann die 
Anhangseldatei auch einen Link auf einen Speicherbereich im 
Server enthalten. In diesem Fall sind die Voreinstellungen 
20 als solche im Server gespeichert, wahrend sie im erstgenann- 
ten Fall im Client gespeichert sind. 

Der Zustand der Sitzung ist iiblicherweise an die Sitzung im 




Sinne der Existenz des korrespondierenden clientseitigen Kom- 
munikationsprogramms , z. B. eines Internetbrowsers wie dem 



Internetexplorer von Microsoft , gebunden. Die Vorgehensweise 
des Standes der Technik funktioniert daher problemlos, solan- 
ge auf Seiten des Clients der Kommunikationsprozess erhalten 
bleibt und die Kommunikation mit dem Server iiber ein einziges 
30 Fenster erfolgt 

Es ist aber allgemein bekannt, dass es moglich ist, in ein 
und demselben Internetbrowser parallel mehrere Fenster zu 
nutzen. Die Erzeugung mehrerer Fenster kann z. B. beim Inter- 
35 netexplorer von Microsoft durch Betatigen der Tastenkombina- 

tion ^Steuerung Oder durch Wahlen der Option "Of fnen in 
neuem Fenster" erfolgen. Auch in diesem Fall bereitet der 
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Standes der Technik noch keine Probleme, wenn auf Seiten des 
Clients zwar mehrere Fenster genutzt werden, in alien Fens- 
tern aber stets dieselben Voreinstellungen benutzt werden. 

Die Vorgehensweise des Standes der Technik versagt aber, wenn 
auf Seiten des Clients mit mehreren Fenstern gearbeitet wird 
und in den Fenstern voneinander verschiedene Voreinstellungen 
getroffen werden sollen. Denn wie bereits erwahnt, ist der 
Server nicht in der Lage, zu unterscheiden, von welchem der 
Fenster die jeweilige Anforderung an ihn iibermittelt wurde. 
Dabei hilft auch die Verwendung der Anhangseldatei nicht wei- 
ter. Denn ein neues Fenster auf Seiten des Clients ist eben 
nur ein eigenes Fenster, nicht aber ein eigener Prozess. So- 
mit benutzen die Fenster die gleichen Anhangseldateieri. 

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Be- 
triebsverfahren fur einen Server, ein hiermit korrespondie- 
rendes Computerprogramm und den entsprechenden Server zu 
schaffen, mittels derer derartige Voreinstellungen individu- 
ell fur jedes client seitige Fenster vorgenoiranen werden kon- 
nen. 

Die Aufgabe wird durch ein Betriebsverf ahren fur einen Ser- 
ver, der mit einem Client kommuniziert, dadurch gelost, 

- dass der Server, wenn ihm vom Client eine Anforderung fur 
eine Seite iibermittelt wird, die angeforderte Seite an den 
Client iibermittelt, 

- dass der Server der Seite Identif izierungsdaten derart bei- 
fiigt, dass die Identif izierungsdaten bei einer weiteren An- 
forderung fur eine Seite vom Client dann und nur dann an 
den Server zuruck iibermittelt werden, wenn die Anforderung 
auf Seiten des Clients von dieser Ubermittlung der Seite 
ausgeht, 

- dass die Identif izierungsdaten zumindest einen fur die 
tibermittlung der Seite spezifischen Ubermittlungsidentif i- 
zierer umfassen, 
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- dass der Server die von ihm iibermittelten Identif izierungs- 
daten abspeichert, 

- dass der Server bei Erhalt der weiteren Anforderung den von 
ihm neu iibermittelten Ubermitt lungs identif izierer anstelle 

5 des zuriick iibermittelten Ubermittlungsidentif izierers ab- 
speichert, wenn der zuriick iibermittelte Ubermi ttlungsiden- 
tifizierer mit einem abspeicherten Ubermi tt lungs identif i- 
zierer ubereinstimmt, und 

- dass der Server bei Erhalt der weiteren Anforderung den von 
10 ihm neu iibermittelten Ubermi ttlungsidentif izierer zusatz- 

lich zum zuriick iibermittelten Ubermitt lungs identif izierer 
^ abspeichert, wenn der zuriick iibermittelte Ubermi tt lungs i- 
JF dentifizierer mit keinem zuvor abspeicherten Ubermittlung- 
sidentif izierer ubereinstimmt. 

15 

Durch diese Vorgehensweise kann der Server namlich zwar noch 
nicht erkennen, wenn auf Seiten des Clients ein zweites Fens- 
ter geoffnet wird (dazu spater). Er kann aber erkennen, wenn 
ihm vom Client "veraltete" Identif izierungsdaten ubermittelt 
20 werden. Anhand dieses Umstands, namlich dass die Identif izie- 
rungsdaten bereits veraltet bzw. iiberholt sind, kann er daher 
erkennen, dass ein zweites Fenster geoffnet worden sein muss. 
Ab dem Zeitpunkt dieser Erkenntnis ist der Server somit in 




der Lage, dieses zweite Fenster getrennt vom ersten Fenster 
zu verwalten. 



Der tfbermittlungsidentifizierer kann im einfachsten Fall eine 
laufende Nummer oder dergleichen sein. Vorzugsweise aber ist 
der Ubermittlungsidentifizierer ein weltweit einmaliger Iden- 

30 tifikator. Beispielsweise kann der Ubermittlungsidentifizie- 
rer ein sogenannter GUID sein. Ein GUID (global universal 
identifier) wird auf die - in der Regel auf eine Millisekunde 
genaue - Zeit des Servers sowie Identif ikationsdaten des Ser- 
vers gebildet, beispielsweise eine nur einmal vergebene Iden- 

35 tifikationsnummer der Netzwerkkarte des Servers oder des Pro- 
zessors des Servers. 
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Durch die erf indungsgemaBe Vorgehensweise ist es beispiels- 
weise moglich, dass den Identif izierungsdaten Selektionsdaten 
zugeordnet sind und dass 1m Falle der Ubereinstimmung des zu- 
riick ubermittelten Ubermittlxingsidentif izierers mit einem der 
5 abgespeicherten Ubermittlungsidentif izierer die vom Server 

auf Grund der weiteren Anf orderung neu an den Client, ubermit- 
telte Seite von den dem iibereinstimmenden Ubermittlnngs iden- 
tif izierer zugeordneten Selektionsdaten abhangt. 

10 Im Falle der Ubereinstiramung des zuriick ubermittelten iiber- 

mittlungsidentif izierers mit keinem der abgespeicherten Uber- 

^ mittlungsidentif izierer sind verschiedene Vorgehensweisen 

& moglich. So kann beispielsweise eine vorbestimmte Startseite 
an den Client ubermittelt werden. Vorzugsweise aber hangt die 

15 vom Server auf Grund der weiteren Anforderung neu an den 

Client ubermittelte Seite von den einem der abgespeicherten 
Ubermitt lungs identif izierer zugeordneten Selektionsdaten ab. 
Diese Selektionsdaten ordnet der Server dann selbstverstand- 
lich auch dem zusatzlich abgespeicherten Ubermittlungsidenti- 

20 f izierer zu. 

Vorzugsweise umfassen die Identif izierungsdaten auch einen 
Fensteridentif izierer. Im Falle der Ubereinstimmung des zu- 
riick ubermittelten Ubermittlungsidentif izierer mit einem der 
abgespeicherten Ubermittlungsidentif izierer wird in diesem 
Fall der Fensteridentif izierer beibehalten. Wenn hingegen der 
zuriick ubermittelte Ubermittlungsidentif izierer mit keinem 
der abgespeicherten Ubermittl\angsidentif izierer iiberein- 
stimmt, ordnet der Server dem zusatzlich abgespeicherten 
Ubermittlungsidentif izierer einen neuen Fensteridentif izierer 
zu. 

Auf Grund dieser Vorgehensweise ist insbesondere eine ef f i- 
ziente Verwaltung von mehr als zwei clientseitigen Fenstern 
35 moglich. Denn auf Grund dieser Vorgehensweise ist fur den 
Server erkennbar r welches Fenster clientseitig dupliziert 
wurde. 
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Auf Grund dieser Vorgehensweise ist es weiterhin mSglich, 
dass im Falle der Ubereinstimmung des zuriick iibermittelten 
Ubermittlungsidentifizierers mit keinem der abgespeicherten 
ttoermittlungsidentifizierer die vom Server auf Grund einer 
weiteren Anforderung neu an den Client ubermittelte Seite von 
den Selektionsdaten abhangt, die demjenigen der abgespeicher- 
ten ubermittlungsidentifizierer zugeordnet sind, dessen Fen- 
steridentif izierer mit dem zuriick iibermittelten Fensteriden- 
tif izierer iibereinstimmt . 

Der neue Fensteridentifizierer kann - analog zum Ubermitt- 
lungsidentifizierer - im einf achsten Fall wieder eine laufen- 
de Nummer sein. Vorzugsweise ist aber auch er als GUID ausge- 
bildet. Dabei kann er alternativ als eigenstandig generierter 
GUID ausgebildet sein oder mit dem unmittelbar zuvor gene- 
rierten ubermittlungsidentifizierer identisch sein. 

Der Server verwaltet die Identif izierungsdaten vorzugsweise 
in Form einer Tabelle, die pro Zeile die Eintrage Fenster- 
identifizierer, Ubermittlungsidentifizierer und Selektionsda- 
ten enthalt. Anstelle der Selektionsdaten selbst kann in der 
Tabelle selbstverstandlich auch ein Verweis (= Pointer) auf 
die Selektionsdaten gespeichert sein. 

Die Prufungsreihenfolge (erst die ubermittlungsidentifizierer 
oder erst die Fensteridentifizierer) ist prinzipiell in das 
Belieben des Fachmanns gestellt. Vorzugsweise wird aber zu- 
erst der Fensteridentifizierer iiberprtift und dann der fiir 
diesen Fensteridentifizierer gespeicherte Ubermittlungsiden- 
tifizierer. Denn der vom Client zuriick ubermittelte Fenster- 
identifizierer ist stets abgespeichert. Der vom Client zuriick 
ubermittelte ubermittlungsidentifizierer hingegen konnte be- 
reits uberschrieben sein. 

Bei Web-Anwendungen sind im Wesentlichen zwei Arten der An- 
forderungsubermittlung bekannt, namlich die sogenannten Post- 
Requests und die sogenannten Get-Requests. 
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Post-Requests beruhen auf dem Prinzip, dass der Client Einga- 
befelder der Seite ausfullt und dann die ausgefiillten Einga- 
bef elder vom Client an den Server zuriick ubermittelt werden. 
Bei Post-Requests werden dabei vom Client stets alle Eingabe- 
f elder an den Server zuriick ubermittelt • Die ubermittelten 
Daten enthalten unter anderem die Anf orderung fur die neue 
Seite. Fiir eine im Sinne der vorliegenden Erfindung ordnungs- 
gemaBe serverseitige Behandlung solcher Post-Requests ist es 
daher beispielsweise moglich, dass der Server die Identif i~ 
zierungsdaten der ubermittelt en Seite als versteckte, auf 
Seiten des Clients nicht mit angezeigte Eingabef elder bei- 
fiigt. ErfindungsgemaB werden also der Seite versteckte Einga- 
bef elder beigefugt, die bei einer ublichen Darstellung der 
Seite in einem Fenster des Clients nicht mit angezeigt wer- 
den. In diesen Eingabef eldern sind von Seiten des Servers be- 
reits vorab die Identif izierungs daten hinterlegt worden. Sie 
werden daher vom Client an den Server zuriick ubermittelt, 
wenn der Client einen Post-Request sendet. 

Bei Get-Requests hingegen wird vom Client unmittelbar eine 
Linkadresse, in der Regel eine sogenannte URL, an den Server 
zuriick ubermittelt. Die Linkadresse ist dabei Bestandteil der 
zuvor iibermittelten Seite und wird in dem Fenster, in dem der 
Client die Seite darstellt, als solche mit angezeigt. Selek- 
tiert der Benutzer des Clients diese Linkadresse, stellt die 
Linkadresse selbst und unmittelbar eine Anforderung fiir eine 
weitere Seite dar. 

Wenn die Seite mindestens eine derartige Adresse fiir eine 
weitere Seite enthalt, kann eine im Sinne der vorliegenden 
Erfindung ordnungsgemafie serverseitige Behandlung eines sol- 
chen Get-Requests dadurch erreicht werden, dass der Server 
die Identif izierungs daten der iibermittelten Seite als der Ad- 
resse zugeordnete Parameter, sogenannte Query-Parameter, bei- 
fiigt. 
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Ein Spezialfall einer Reaktion des Servers auf den Erhalt ei- 
ner Anf orderung 1st ein sogenannter serverseitiger Response- 
Redirect. Ein serverseitiger Response-Redirect liegt vor f 
wenn der Server auf Grund einer an ihn iibermittelten Anforde- 
rung nicht die angeforderte Seite an den Client ubennittelt, 
sondern bei Erhalt der weiteren Anforderung zunachst eine 
dritte, vom Client wieder an den Server zuriick zu sendende 
Anforderung an den Client ubermittelt. Erst auf Grund der 
Ubermittlung der dritten Anforderung an den Server ubermit- 
telt der Server dann die angeforderte Seite. In diesem Fall 
gibt es zwei Moglichkeiten, serverseitig eine im Sinne der 
vorliegenden Erf indung ordnungsgemaBe Behandlung der Anforde- 
rung zu gewahrleisten. 

Zum einen ist es moglich, dass der Server die Identifizie- 
rungsdaten der dritten Anforderung als zugeordnete Parameter 
beifiigt. In diesem Fall werden die Identif izierungsdaten der 
Anforderung selbst beigefiigt. Alternativ ist es auch moglich 
dass der Server die Identif izierungsdaten der dritten Anfor- 
derung als Anhangseldatei beifiigt , die vom Client nicht der 
dritten Anforderung an den Server zuriick ubermittelt mit. In 
diesem Fall fiigt der Server die Identif izierungsdaten der 
dritten Anforderung also als sogenanntes Trans fercookie bei. 
Die Identifizierungsdaten sind der Seite dabei wie auch bei 
Post-Requests als versteckte Daten beigefiigt. Das Programm 
extrahiert die Identifizierungsdaten und fiigt sie in die An- 
hangseldatei ein. Weiterhin ubermittelt der Server zusammen 
mit der Seite , die er auf Grund der dritten Anforderung an 
den Client ubermittelt r einen Loschbefehl fur diese Anhang- 
seldatei an den Client. 

Es gibt Sprachen, bei denen den vom Server an den Client 
iibermittelten Seiten Programme beigefiigt bzw. die Programme 
in diese Seiten eingebettet sein konnen. Ein Beispiel einer 
solchen Sprache ist JavaScript. In diesem Fall gibt es eine 
weitere M5glichkeit, zu gewahrleisten , dass die Identifizie- 
rungsdaten zusammen mit der Anforderung vom Client an den 
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Server tibermittelt werden. Denn in dies em Fall ist es mog- 
lich, dass der Server die Identif izierungsdaten der Seite da- 
durch beifiigt, dass er der Seite ein Prograram beifiigt, auf 
Grund dessen der Client einer Anforderung fur eine Seite dann 
5 und nur dann eine die Identif izierungsdaten enthaltende An- 
hangseldatei beifugt, wenn die Anforderung von dieser Uber- 
mittlung der Seite ausgeht. 

In diesem Fall wird also ebenfalls ein sogenanntes Transfer- 
cookie erzeugt. Die Erzeugung des Transf ercookies erfolgt 
aber im Gegensatz zum Response-Redirect nicht serverseitig / 
sondern client seitig. 

Der Server kann nicht unmittelbar erkennen, wenn auf Seiten 
des Clients eine Duplizierung einer bereits an den Client 
ubertragenen Seite erfolgt. Wenn daher der Benutzer des 
Clients eine Seite dupliziert und danach langere Zeit mit nur 
einer der beiden Versionen der duplizierten Seite arbeitet, 
die andere Version der duplizierten Seite aber nicht veran- 
dert, bleibt diese andere Version vorerst unverandert erhal- 
ten. Wenn der Benutzer des Clients dann zu einem erheblich 
spateren Zeitpunkt von der anderen, noch unveranderten Versi- 
on der duplizierten Seite eine Anforderung an den Server sen- 
det, iibernimmt der Server in diesem Fall die Selektionsdaten, 
die der veranderten Version der duplizierten Seite zu diesem 
Zeitpunkt zugeordnet sind. Die Selektionsdaten konnen zu die- 
sem Zeitpunkt aber bereits erheblich geandert worden sein. 
Die Restaurierung des vom Benutzer eigentlich gewtinschten Zu- 
stands der anderen Version der duplizierten Seite kann fur 
den Benutzer daher relativ aufwandig sein. Aus diesem Grund 
ist es von Vorteil, so friih wie moglich zu erkennen, wenn auf 
Seiten des Clients eine bereits an diesen ubermittelte Seite 
dupliziert wird. 

35 Ein sofortiges Erkennen eines solchen Duplizierens ist da- 
durch moglich, 
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- dass der Server der Seite auch eine Variable mit einem An- 
fangswert und ein vom Client beim Darstellen der Seite in 
einem Fenster auszuftihrendes Programm beiftigt, 

- dass der Client auf Grund des Programms den Wert der Vari- 
able, wenn sie den Anf angswert aufweist, abandert und 

- dass der Client auf Grund des Programms die vorherige An- 
forderung zur Ubermittlung der Seite wiederholt, so dass 
der Client, wenn die Variable nicht den Anf angswert auf- 
weist, die bei der vorherigen Anforderung iibermittelten 
Identifizierungsdaten ein zweites Mai an den Server iiber- 
mittelt. 

Denn dann wiederholt der Client die vorherige Anforderung so- 
fort beim Duplizieren der Seite, so dass der Server die Dup- 
lizierung als solche sofort erkennen kann. Der Server erkennt 
bei dieser Vorgehensweise zwar auch dann (falschlicherweise) 
eine Duplizierung, wenn der Benutzer des Clients - ohne die 
Seite zu duplizieren - diese nur aktualisiert oder auf eine 
clientseitig noch gespeicherte, in diesem Fenster aber nicht 
mehr angezeigte Seite zuruck greift. Dies ist aber unkri- 
tisch, da in diesem Fall auf Seiten des Servers lediglich ein 
Fenster verwaltet wird, das auf Seiten des Clients in der Re- 
alitat gar nicht existent ist. Hingegen kann es nicht gesche- 
hen, dass auf Seiten des Clients ein Fenster dupliziert wird 
und der Server dies nicht erkennt. Die Anforderung kann dabei 
je nach Anwendungsf all in Form eines Post- oder in Form eines 
Get-Requests an den Server ubermittelt werden. Dies gilt auch 
dann, wenn das erstmalige Laden der Seite auf Grund eines 
Post-Requests erfolgte. 

Das erfindungsgemaBe Betriebsverf ahren ist als Computerpro- 
gramm realisiert, das dem Server zugefuhrt wird. Das Compu- 
terprogramm wird dem Server dabei tiber einen Datentrager zu- 
gefiihrt. Beispiele eines derartigen Datentragers sind eine 
CD-ROM oder eine Streamerkassette . Auf dem Datentrager ist 
das computerprogramm in (ausschliefllich) maschinenlesbarer 
Form gespeichert. Das Computerprogramm kann auf dem Datentra- 



2003 P 15792 DE 



11 

ger dabei alternativ in komprimierter oder in unkomprimieirter 
Form gespeichert sein. 

Der Datentrager mit dem darauf gespeicherten Computerprogramm 
wird in ein Lesegerat eingefuhrt, mittels dessen der Server 
das auf dem Datentrager gespeicherte Computerprogramm lesen 
kann. Er liest daher das Computerprogramm vom Datentrager aus 
und speichert es in einem Massenspeicher ab, beispielsweise 
auf einer Festplatte. Bei Aufruf des Computerprogramms von 
der Festplatte (alternativ auch vom Datentrager) ist der Ser- 
ver daher in der Lage, das erf indungsgemafle Betriebsverf ahren 
auszufiihren. 

Weitere Vorteile und Einzelheiten ergeben sich aus der nach- 
folgenden Beschreibung eines Ausfuhrungsbeispiels in Verbin- 
dung mit den Zeichnungen. Dabei zeigen 

FIG 1 einen Rechnerverbund, 

FIG 2 ein Ablauf diagraram, 

FIG 3 eine Tabelle und 

FIG 4 bis 7 weitere Ablauf diagramme . 

GemaB FIG 1 ist ein Server 1 liber eine Rechner-Rechner-Ver- 
bindung 2 mit einem Client 3 datentechnisch verbunden. Die 
Rechner-Rechner-Verbindung 2 kann dabei auf verschiedene Art 
ausgebildet sein. In der Regel ist sie jedoch als Intemet- 
oder als Intranet-Verbindung ausgebildet. tiber die Rechner- 
Rechner-Verbindung 2 konnen der Server 1 und der Client 3 ge- 
maB einem Web-Protokoll miteinander kommunizieren. 

Der Server 1 weist, wie allgemein iiblich^ mehrere Komponenten 
4 bis 8 auf f die iiber einen Bus 9 miteinander verbunden sind. 
Die Komponenten 4 bis 8 umfassen insbesondere einen Prozessor 
4, einen Massenspeicher 5 (typisch eine oder mehrere Fest- 
platten), ein Lesegerat 6 f einen Zeitgeber 7 und eine Netz- 
werkkarte 8. 
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In das Lesegerat 6 1st ein Datentrager 10 einfuhrbar, auf dem 
in ausschlieBlich maschinenlesbarer Form ein Computerprogramm 
11 gespeichert ist. Dieses Computerprogramm 11 wird von dem 
Datentrager 10 ausgelesen und, wie in FIG 1 gestrichelt ange- 
deutet ist, im Massenspeicher 5 hinterlegt. Bei Aufruf des 
Computerprogramms 11 ist der Server 1 daher in der Lage, das 
Computerprogramm 11 auszufuhren. Bei Aufruf des Computerpro- 
gramms 11 fiihrt der Server 1 dabei ein Betriebsverf ahren aus, 
das nachf olgend in Verbindung mit FIG 2 naher beschrieben 
wird. 

GemaB FIG 2 nimmt der Server 1 in einem Schritt SI vom Client 
3 eine Anmeldung und eine erste Anforderung fiir eine Seite 
entgegen. Der Server 1 ermittelt daraufhin in einem Schritt 
S2 einen ubermittlungsidentif izierer iibld. Der Ubermitt lungs - 
identifizierer iibld ist dabei vorzugsweise weltweit einmalig. 
Beispielsweise kann er aus einer Kombination der vom Zeitge- 
ber 7 ausgegebenen Zeit und dem Code der Netzwerkkarte 8 
und/ oder des Prozessors 4 bestehen. 

In einem Schritt S3 wird sodann ein Fensteridentif izierer 
Feld gleich dem soeben ermittelten ubermittlungsidentif izie- 
rer iibld gesetzt. Die beiden Identifizierer iibld, Feld werden 
sodann - siehe erganzend FIG 3 - in die erste Zeile einer Ta- 
belle 12 eingetragen. GemaB FIG 3 konnen dabei jeder Zeile 
der Tabelle 12 auBer den beiden Identif izierern iibld, Feld 
auch noch Selektionsdaten SD zugeordnet werden. Auf die Be- 
deutung der Selektionsdaten SD wird nachstehend noch einge- 
gangen werden. 

In einem Schritt S5 fugt der Server 1 der angef orderten Seite 
die Identif izierungsdaten Feld, iibld bei. Die Beifiigung er- 
folgt dabei derart, dass die Identif izierungsdaten Feld, iibld 
bei einer weiteren Anforderung fur eine Seite vom Client 3 
dann und nur dann an den Server 1 zuriick ubermittelt werden, 
wenn die Anforderung auf Seiten des Clients 3 von der iiber- 
mittlung dieser Seite ausgeht. 
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Gemafl einem Schritt S6 fiigt der Server 1 weiterhin der ange- 
forderten Seite eine Variable und ein Programm bei. Die Vari- 
abel weist einen Anfangswert auf . Das Programm ist derart 
ausgestaltet, dass es bei einem clientseitigen Kopieren der 
iibertragenen Seite eine Neuanf orderung der bisherigen Seite 
auslost. Hierauf wird spater noch naher eingegangen werden. 
Der Schritt S6 ist dabei nur optional und daher in FIG 2 nur 
gestrichelt dargestellt. In einem Schritt S7 ubermittelt der 
Server 1 sodann die angeforderte Seite einschliefllich der 
dieser Seite beigefiigten Inf ormationen an den Client 3. 

In einem Schritt S8 nimmt der Server 1 vom Client 3 eine wei- 
tere Eingabe entgegen. Der Server 1 iiberpriift daraufhin zu- 
nachst in einem Schritt S9, ob der Client 3 sich abgemeldet 
hat. Wenn dies der Fall ist, loscht er in einem Schritt S10 
die Tabelle 12 und beendet die Ausfuhrung des Verfahrens. 

Bei den beigefvigten Inf ormationen handelt es sich insbesonde- 
re um die beiden beigefiigten Identif izierer Ubld, Feld, deren 
Erganzungen sowie die Variable und das Programm. 

Wenn die Eingabe des Schrittes S8 keine Abmeldung war, war 
sie eine neue Anf orderung. In diesem Fall extrahiert der Ser- 
ver 1 aus der ubermittelten Anforderung die zuriick iibermit- 
telten Identif izierer Ubld, Feld sowie die Selektionsdaten 
SD. 

In einem Schritt S12 uberpruft der Server 1 sodann , ob der 
zuruck ubermittelte Ubermitt lungs identif izierer Ubld mit dem 
Ubermittlungsidentif izierer Ubld iibereinstimmt, der in der 
Tabelle 12 dem zuruck ubermittelten Fensteridentif izierer 
Feld zugeordnet ist. Der besseren Ubersichtlichkeit halber 
ist der Schritt S12 in FIG 2 dabei in zwei Teilschritte S12a, 
S12b aufgeteilt. Im Teilschritt Sl2a wird eine logische Vari- 
able entsprechend der vorzunehmenden Prufung belegt, im Teil- 
schritt S12b die logische Variable abgefragt. 
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Wenn im Schritt S12 eine Ubereinstimmung ermittelt wurde, 
geht die vom Client 3 iibermittelte Anforderung von einem ser- 
ver seitig bereits erf ass ten und verwalteten Fenster des 
Clients 3 aus. In diesem Fall wird in einem Schritt S13 ana- 
5 log zum Schritt S2 ein neuer Ubermittlungsidentif izierer ttbld 
ertaittelt und in der Tabelle 12 in der Zeile abgespeichert, 
in der auch der zuriick tibermittelte Fensteridentif izierer 
Feld abgespeichert ist. Der Server 1 speichert also den neu 
ermittelten Ubermittlungsidentif izierer Ubld anstelle des zu- 
10 ruck ubeimittelten Ubermittlungsidentif izierer Ubld in der 
_ Tabelle 12 ab. 

Wenn im Schritt S12 hingegen keine Ubereinstiiraniing festge- 
stellt wurde, wird ein Schritt S14 ausgefiihrt. Im Schritt S14 

15 wird ebenfalls der Ubermittlungsidentif izierer Ubld analog 

zur Vorgehensweise von Schritt S2 neu ermittelt. Sodann wird 
aber der Fensteridentif izierer Feld analog zum Schritt S3 
gleich dem soeben neu ermittelten Ubermittlungsidentif izierer 
Ubld gesetzt. Beide Identif izierer Feld, tibld werden vom Ser- 

2 0 ver 1 in eine neue Zeile der Tabelle 12 eingetragen. Ferner 
werden im Rahmen des Schrittes S14 noch die Selektionsdaten 
SD, die dem zuriick ubermittelten Fensteridentif izierer Feld 
zugeordnet sind, in die nunmehr neu belegte Zeile der Tabelle 
12 kopiert. 

Falls der Server 1 neue Selektionsdaten SD erhalten hat, an- 
dert er ferner in einem Schritt S15 die Selektionsdaten SD 
ab, die dem aktuellen Fensteridentif izierer Feld zugeordnet 
sind. Je nach dem, ob auf Grund der Prufung im Schritt S12 
30 der Schritt S13 oder der Schritt S14 durchlaufen wurde, han- 
delt es sich dabei urn den zuriick iibermittelten Fensteridenti- 
f izierer Feld oder urn den neu ermittelten Fensteridentif izie- 
rer Feld. 

35 In einem Schritt S16 tiberpruft der Server 1 als nachstes, ob 
er die angef orderte Seite direkt ubermitteln kann oder ob er 
ein sogenanntes Response-Redirect durchfiihren muss. Wenn er 
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ein Response-Redirect durchfiihren muss, ftihrt er einen 
Schritt S17 aus, in dem er eine neue Adresse, in der Regel 
eine URL-Adresse zuziiglich des aktuellen Fensteridentif izie- 
rers Feld und des aktuellen Ubermittlungsidentif izierers iibld 
an den Client 3 ubermittelt. Sodann springt er zum Schritt S8 
zurtick. 

Anderenfalls ermittelt der Server 1 anhand der Selektionsda- 
ten, die dem aktuellen Fensteridentif izierer Feld und dem ak- 
tuellen Ubermittlungsidentifizierer Ubld in der Tabelle 12 
zugeordnet sind, welche Seite an den Client 3 ubermittelt 
werden soli. Alternativ oder erganzend kann auch der Inhalt 
der Seite modifiziert werden. Sodann springt der Server 1 zum 
Schritt S5 zuriick. 

FIG 4 zeigt eine erste Moglichkeit, die Identifizierungsdaten 
Ubld, Feld der zu tibermittelnden Seite beizufiigen. Gemafi FIG 
4 fiigt der Server 1 der Seite die Identif izierer iibld, Feld 
in einem Schritt S19 zunachst als versteckte Eingabef elder 
bei. Dadurch ergibt sich die Wirkung, dass die Identif izierer 
iibld und Feld bei jedem Post-Request des Clients 3, der von 
dieser Seite ausgeht, vom Client 3 an den Server 1 ubermit- 
telt werden. 

In einem Schritt S20 iiberpriift der Server 1 sodann, ob die zu 
ubermittelnde Seite eine URL-Adresse enthalt, der die Identi- 
fizierer iibld und Feld noch nicht als Query-Parameter beige- 
fiigt wurden. Wenn dies der Fall ist, fiihrt der Server 1 einen 
Schritt S21 aus, in dem er dieser Adresse die Identif izierer 
iibld und Feld als Query-Parameter beifugt. Vom Schritt S21 
geht der Server dann zum Schritt S20 zuriick. Der Schritt S20 
ist dabei in FIG 4 - analog zum Schritt S12 von FIG 2 - in 
zwei Teilschritte unterteilt. 

FIG 5 zeigt eine weitere MBglichkeit, die Identifizierungsda- 
ten iibld, Feld der Seite beizuftigen. Gemafl FIG 5 fiigt der 
Server 1 der Seite die Identif izierer iibld und Feld als ver- 
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steckte Daten bei. Dabei kann es sich - analog zum Schritt 
S19 von FIG 4 - urn versteckte Eingabef elder handeln. Dies 1st 
aber nicht zwingend erf orderlich . Sodann fiigt der Server 1 
der Seite ein Programm bei, das bei einer Anforderung des 
Clients 3, die von dieser Seite ausgeht, ausgefiihrt wird. Auf 
Grund des Programms extrahiert dann der Client 3 aus dieser 
Seite die Identif izierungsdaten tibld, Feld und bindet sie in 
ein von inm zu kreierendes Cookie ein. Das Cookie sendet der 
Client 3 zusammen mit der Anforderung an den Server 1. 

FIG 6 zeigt die Moglichkeiten, die bestehen, urn den Schritt 
S17 von FIG 2, in dem die Identif izierer Feld und Ubld der zu 
ubermittelnden URL beigefiigt werden, zu implementieren . GemaB 
FIG 6 1st es mBglich, den Schritt S17 derart auszugestalten, 
dass die Identifizierer Ubld und Feld - analog zum Schritt 
S21 von FIG 4 - der URL-Adresse als Query-Parameter beigefiigt 
werden. Altemativ ist es moglich, dass der Server 1 im 
Schritt S17 der URL-Adresse eine Anhangseldatei (Cookie) bei- 
fiigt, welche die Identifizierer tibld, Feld enthalt. In diesem 
, letzteren Fall sollten die im Schritt S7 (siehe FIG 2) der 
angeforderten Seite beigefilgten Informationen an den Client 3 
einen Ldschbefehl enthalten, auf Grund dessen diese Anhang- 
seldatei auf seiten des Clients 3 sofort wieder geloscht 
wird. 

Von den in FIG 6 dargestellten Schritten S17 wird stets nur 
einer ausgefiihrt. Die beiden Schritte S17 sind daher in FIG 6 
gestrichelt dargestellt. 

30 FIG 7 zeigt nun der Vollstandigkeit halber das Verfahren, das 
der Client 3 auf Grund des Programms ausfuhrt, das vom Server 
1 im Rahmen des Schrittes S6 (siehe FIG 2) der angeforderten 
Seite beigefiigt wird. Das Programm wird dabei vom Client 3 
stets ausgefiihrt, wenn die Seite von ihm in einem Fenster 

35 dargestellt wird. Das Programm wird also sowohl dann ausge- 
fiihrt, wenn der Client 3 die Seite erstmals erhalt, als auch 
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dann, wenn der Client 3 die Seite beispielsweise mit "Steue- 
rung N" dupliziert. 

Gemafl FIG 7 extrahiert der Client 3 zunachst aus der Seite 
5 die ubermittelte Variable. In einem Schritt S25 uberpruft er 
dann, ob die Variable noch ihren Anfangswert hat. Wenn dies 
der Fall ist, setzt er die Variable in einem Schritt S26 auf 
ihren Endwert. Der Endwert muss dabei selbstverstandlich vom 
Anfangswert verschieden sein. Ansonsten kann er beliebig ge- 
10 wahlt sein. Wenn die Priifung im Schritt S25 keine Uberein- 
st±mmung ergeben hat, fiihrt der Client 3 einen Schritt S27 

• aus, in dem er die vorherige Anforderung wiederholt. Die Wie- 
derholung der Anforderung bewirkt dabel insbesondere, dass 
die bereits an den Server 1 zuruck ubermittelten Identifizie- 
15 rungsdaten Ubld, Feld ein zweites Mai an den Server 1 uber- 
mittelt werden. Dadurch ist dann der Server 1 sofort in der 
Lage, zu erkeimen, dass clientseitig ein neues Fenster geoff- 
net wurde. 

20 Mittels des erf indungsgemaBen Betriebsverf ahrens ist es somit 
auf einfache Weise moglich, dass der Server 1 individuell 
mehrere Fenster des Clients 3 verwaltet. 



2003 P 15792 DE 



18 

Patentanspriiche 

1 • Betriebsverf ahren fur einen Server ( 1 ) , der mit einem 
Client (3) kommuniziert, 

- wobei der Server ( 1 ) , wenn ihm vom Client ( 3 ) eine Anf orde- 
rung fur eine Seite ubermittelt wird, die angeforderte Sei- 
te an den Client (3) ubermittelt , 

- wobei der Server (1) der Seite Identif izierungsdaten (tibld, 
Feld) derart beifugt, dass die Identif izierungsdaten (tibld, 
Feld) bei einer weiteren Anforderung fur eine Seite vam 
Client (3) dann und nur dann an den Server (1) zuruck uber- 
mittelt werden, wenn die Anforderung auf Seiten des Clients 
(3) von dieser tibermittlung der Seite ausgeht, 

- wobei die Identif izierungsdaten (Ubld, Feld) zumindest ei- 
nen fur die tibermittlung der Seite spezifischen tibermitt- 
lungsidentifizierer (Ubld) umfassen, 

- wobei der Server (1) die von ihm iibermittelten Identif izie- 
rungsdaten (Ubld) abspeichert, 

- wobei der Server (1) bei Erhalt der weiteren Anforderung 
den von ihm neu iibermittelten Ubermitt lungs identif izierer 
(tibld) anstelle des zuruck iibermittelten Ubermitt lungs iden- 
tif izierers (tibld) abspeichert, wenn der zuruck ubermittel- 
te Ubermittlungsidentif izierer (Ubld) mit einem abspeicher- 
ten Ubermittlungsidentif izierer (Ubld) ubereinstimmt, und 

- wobei der Server (1) bei Erhalt der weiteren Anforderung 
den von ihm neu iibermittelten Ubermittlungsidentif izierer 
(tibld) zusatzlich zum zuruck iibermittelten Ubermittlungsi- 
dentif izierer (tibld) abspeichert, wenn der zuruck iibermit- 
telte Ubermittlungsidentif izierer (tibld) mit keinem zuvor 
abspeicherten Ubermittlungsidentif izierer (tibld) iiberein- 
stimmt. 

2. Betriebsverf ahren nach Anspruch 1, 

dadurch gekennzeichnet, 

dass den Identif izierungsdaten (tibld, Feld) Selektionsdaten 

(SD) zugeordnet sind und dass im Falle der tibereinstimmung 

des zuruck iibermittelten Ubermittlungsidentif izierers (tibld) 
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mit einem der abgespeicherten ubermittlungsidentif izierer 
(ubld) die vom Server (1) auf Grund der weiteren Anforderung 
neu an den Client (3) ubermittelte Seite von den dem iiberein- 
stimmenden ubermittlungsidentif izierer (ubld) zugeordneten 
Selektionsdaten (SD) abhangt. 

3. Betriebsverf ahren nach Anspruch 2, 
dadurch gekennzeichnet, 

dass im Falle der Ubereinstimmung des zuriick ubermittelten 
Ubermittlungsidentif izierers (Ubld) mit keinem der abgespei- 
cherten ubermittlungsidentif izierer (Ubld) die vom Server (1) 
auf Grund der weiteren Anforderung neu an den Client (3) 
ubermittelte Seite von den einem der abgespeicherten Uber- 
mittlungsidentif izierer (iibld) zugeordneten Selektionsdaten 
(SD) abhangt und dass der Server (1) diese Selektionsdaten 
(SD) dem zusatzlich abgespeicherten ubermittlungsidentif izie- 
rer (Ubld) zuordnet. 

4. Betriebsverf ahren nach Anspruch 1, 2 oder 3, 
dadurch gekennzeichnet, 

- dass die Identif izierungsdaten (Ubld, Feld) auch einen 
Fensteridentifizierer (Feld) umfassen, 

- dass der Server (1) im Falle der ubereinstimmung des zuriick 
ubermittelten Ubermittlungsidentif izierers (Ubld) mit einem 
der abgespeicherten ubermittlungsidentif izierer (iibld) den 
Fensteridentifizierer (Feld) des ubereinstimmenden Uber- 
mittlungsidentif izierers (Ubld) beibehalt und 

- dass der Server im Falle der Ubereinstimmung des zuriick 
Ubermittelten Ubermittlungsidentif izierers (iibld) mit kei- 
nem der abgespeicherten Ubermittlungsidentif izierer (iibld) 
dem zusatzlich abspeicherten ubermittlungsidentif izierer 
(iibld) einen neuen Fensteridentifizierer (Feld) zuordnet. 

5. Betriebsverf ahren nach Anspruch 3 und 4, 

dadurch gekennzeichnet, 

dass im Falle der ubereinstimmung des zuriick ubermittelten 

Ubermittlungsidentif izierers (iibld) mit keinem der abgespei- 
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cherten Uberaiittlungsidentif izierer (Ubld) die vom Server (1) 
auf Grund einer weiteren Anforderung neu an den Client. (3) 
ubermittelte Seite von den Selektionsdaten (SD) abhangt, die 
demjenigen der abgespeicherten Ubermitt lungs identif izierer 
(tibld) zugeordnet sind, dessen Fensteridentif izierer (Feld) 
mit dem zuriick ubermittelten Fensteridentif izierer (Feld) 
iibereinstimmt . 

6. Betriebsverf ahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

dass der Server (1) die Identif izierungsdaten (tibld, Feld) 
der ubermittelten Seite als versteckte, auf Seiten des 
Clients (3) nicht mit angezeigte Eingabef elder beifugt. 

7. Betriebsverf ahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

dass die Seite mindestens eine Adresse fiir eine weitere Seite 
enthalt und dass der Server (1) die Identif izierungsdaten 
(tibld, Feld) der ubermittelten Seite als der Adresse zugeord- 
nete Parameter beifugt. 

8. Betriebsverf ahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

dass der Server (1) bei Erhalt der weiteren Anforderung zu- 
nachst eine dritte, vom Client (3) wieder an den Server (1) 
zuriick zu sendende Anforderung an den Client (3) iibemiittelt 
und dass der Server (1) die Identif izierungsdaten (Ubld, 
Feld) der dritten Anforderung als zugeordnete Parameter bei- 
fiigt. 

9. Betriebsverf ahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

dass der Server (1) bei Erhalt der weiteren Anforderung zu- 
nachst eine dritte, vom Client (3) wieder an den Server (1) 
zuriick zu sendende Anforderung an den Client (3) ubermittelt, 
dass der Server (1) die Identif izierungsdaten (Ubld, Feld) 
der dritten Anforderung als Anhangseldatei beifugt, die vom 
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Client (3) mit der dritten Anforderung an den Server (1) zu- 
ruck ubermittelt wird, und dass der Server (1) zusammen mit 
der auf Grund der dritten Anforderung an den Client (3) uber- 
mittelten Seite einen Loschbefehl fur diese Anhangseldatei an 
den Client (3) ubermittelt. 

10. Betriebsverfahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

dass der Server (1) die Identifizierungsdaten (Ubld, Feld) 
der Seite dadurch beifugt, dass er der Seite ein Programm 
beifugt, auf Grund dessen der Client (3) einer Anforderung 
fiir eine Seite dann und nur dann eine die Identifizierungsda- 
ten (tibld, Feld) enthaltende Anhangseldatei beifugt, wenn die 
Anforderung von dieser Ubermittlung der Seite ausgeht. 

11. Betriebsverfahren nach einem der obigen Anspriiche, 
dadurch gekennzeichnet, 

- dass der Server (1) der Seite auch eine Variable mit einem 
Anfangswert und ein vom Client (3) beim Darstellen der Sei- 
te in einem Fenster auszufuhrendes Programm beifugt, 

- dass der Client (3) auf Grund des Programms den Wert der 
Variable, wenn sie den Anfangswert aufweist, abandert und 

- dass der Client (3) auf Grund des Programms die vorherige 
Anforderung zur Ubermittlung der Seite wiederholt, so dass 
der Client (3), wenn die Variable nicht den Anfangswert 
aufweist, die bei der vorherigen Anforderung ubermittelten 
Identifizierungsdaten (Ubld, Feld) ein zweites Mai an den 
Server ( 1 ) ubermittelt . 

12. Datentrager mit einem auf dem Datentrager gespeicherten 
Computerprogramm (11) zur Durchfiihrung eines Betriebsverf ah- 
rens nach einem der obigen Anspriiche. 

13. Server mit einem Massenspeicher (5), in dem ein Computer- 
programm (11) hinterlegt ist, so dass bei Aufruf des Compu- 
terprogramms (11) von dem Server ein Betriebsverfahren nach 
einem der Anspriiche 1 bis 11 ausfiihrbar ist. 
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Zus ammenf as sung 

Betriebsverf ahren fur einen Server und hiermit korrespondie- 
rende Gegenstande 

5 

Ein Server (1) kommuniziert mit einem Client (3), indem er 
diesem vom Client. (3) angeforderte Seiten iibermittelt. Er 
fiigt den Seiten aber Identif izierungsdaten (Ubld, Feld) , die 
zumindest einen fur die Ubermittlung der Seite spezifischen 

10 Ubennittlungsidentifizierer (Ubld) umfassen, derart bei, dass 

^ sie bei einer weiteren Anf orderung fiir eine Seite vom Client 
(3) dann und nur dann an den Server (1) zuriick iibermittelt 
werden, wenn die Anf orderung auf Seiten des Clients (3) von 
dieser Ubermittlung der Seite ausgeht. Ferner speichert der 

15 Server (1) die von ihm iibermittelten Identif izierungsdaten 

(Ubld, Feld) ab. Stimmt der zuriick iibentiittelte Ubermittlung- 
sidentifizierer (Ubld) mit einem abspeicherten Ubermittlung- 
sidentifizierer (iibld) uberein, so speichert der Server (1) 
bei Erhalt der weiteren Anf orderung den von ihm neu ubermit- 

20 telten Ubermittlungsidentif izierer (ttbld) anstelle des zuriick 
iibermittelten Ubermittlungsidentif izierer s (iibld) ab. Ande- 
renfalls speichert er ihn zusatzlich zum zuriick iibermittelten 
Ubermittlungsidentif izierer (tibld) ab. 
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